Ecommerce system with payment data division

ABSTRACT

In at least one embodiment of an ecommerce system, payment data is divided into proper subsets and distributed among multiple data processing systems, and each of the data processing systems stores less than all of the subsets of the payment data after the subsets of payment data are distributed and until at least sending the payment data to a payment authorization system for processing. In at least one embodiment, distributing proper subsets of the payment data among multiple data processing systems enhances security of the payment data by limiting an amount of time and the locations in which a complete set of payment data is persisted.

CROSS-REFERENCE TO RELATED APPLICATION

The present application is a continuation application of U.S. patentapplication Ser. No. 13/737,476 filed Jan. 9, 2013, which claimspriority to U.S. patent application Ser. No. 13/558,198 filed Jul. 25,2012, which claims priority to U.S. Provisional Patent Application No.61/526,971 filed on Aug. 24, 2011, all of which are incorporated hereinby reference in their entirety.

BACKGROUND

The present disclosure relates in general to the field of dataprocessing, and more specifically to a method and system for dividingpayment data.

DESCRIPTION OF THE RELATED ART

Many customers and merchants transact business via an electronicnetwork, such as the Internet. Most transactions involving the Internet(“on-line transactions”) involve some form of payment and often involvepayment via a payment mechanism, such as a credit card or electronicchecking, that involves payment data electronically sent by the customerand stored by the merchant or a third party.

Payment data represents data that can be used to pay for a commercialtransaction. Exemplary payment data for a credit card holder (alsoreferred to as a “cardholder”) includes a cardholder name, a cardholderbilling address, a credit card number, credit card security code, creditcard expiration month, and credit card expiration year. Other paymentdata can include a credit card issue month and a card issue year.Misappropriation of payment data can result in credit card fraud,substantial financial loss, credit rating injuries, and otherundesirable consequences to both the customer and the merchant.

Organizations have established standards to provide security in theexchange of sensitive information such as payment data. For example, forcredit card transactions, the Payment Card Industry Security StandardsCouncil (PCI SSC) established a payment card industry data securitystandard (PCI DSS) to provide an information security standard fororganizations that handle credit card holder information for many debit,credit, prepaid, e-purse, automated teller machine (ATM), and point ofsale (POS) cards. The PCI DSS standard is intended to increase controlsaround cardholder data to enhance payment card data security and, thus,for example, reduce credit card fraud and provide consumer confidence inengaging in credit card transactions, particularly on-line credit cardtransactions.

FIG. 1 depicts an exemplary ecommerce system 100 having a PCI DSScompliant merchant server system 106. The ecommerce system 100 includesa client computer system 102 that engages in ecommerce activity with themerchant server system 106. In at least one embodiment, the clientcomputer system 102 is a computer system that includes a web browsersoftware application 104 to allow a user of the client computer system102 to receive and transmit data via the Internet. Examples of webbrowser 104 are Internet Explorer available from Microsoft Corporationof Washington, US and Firefox available from Mozilla of California, US.The client computer system 102 via web browser 104 allows a user of theclient computer system 102 to browse web pages 108 provided by andinteract with the merchant server system 106 via a network, such as theInternet or a private network.

To capture payment data from the user, the web browser 104 presents apayment form to the user, and the user enters payment data into theform. The web browser 104 captures the payment data in the form andprovides the payment data 110 to the merchant server system 106.Generally the payment data 110 is encrypted and provided via a secureconnection, such as via a secure sockets layer. Providing the paymentdata 110 can be in response to a request to purchase one or moreproducts and/or services offered by the merchant server system 106 orcan be in anticipation of a future purchase. The merchant server system106 stores the payment data 110 along with a user identification code toassociate the user with the user's payment data 110.

To authorize payment from the user to the merchant, the merchant serversystem 106 sends the payment data, merchant data, and a paymentauthorization request 112 to a payment authorization system 116. Thepayment authorization system 116 then provides a payment authorizationresponse 118 to the merchant server system 106. The paymentauthorization response 118 can indicate approval or denial of payment.The payment authorization system 118 can be any system that providespayment authorization services and, in at least one embodiment, includesa payment gateway and a card association. Companies such asAuthorize.Net with offices in Mountain View, Calif., Skipjack FinancialServices in Cincinnati, Ohio, Sage Pay, London, England offer paymentgateway services. Companies such as Visa, MasterCard, American Express,and Discover Card offer card association services.

Typically, to be authorized to conduct credit card payment transactions,the merchant server system 106 complies with the PCI DSS. Compliancewith PCI DSS can be relatively expensive in terms of, for example, aninvestment in secure facilities, secure hardware and software,encryption technology, and compliance verification. However, merchantcompliance with PCI DSS has been considered as a reasonable way toprotect payment data from misappropriation and provide consumerconfidence in providing payment data via a public network, such as theInternet.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be better understood, and its numerousobjects, features and advantages made apparent to those skilled in theart by referencing the accompanying drawings. The use of the samereference number throughout the several figures designates a like orsimilar element.

FIG. 1 depicts an ecommerce system having a PCI DSS compliant merchantserver system.

FIG. 2 depicts an ecommerce system having for dividing payment data.

FIG. 3 depicts an ecommerce system, which represents one embodiment ofthe ecommerce system of FIG. 2.

FIG. 4 depicts a payment data division and separation process.

FIG. 5 depicts an ecommerce system, which represents one embodiment ofthe ecommerce system of FIG. 3.

FIG. 6 depicts an ecommerce system, which represents one embodiment ofthe ecommerce system of FIG. 5.

FIG. 7 depicts an ecommerce system, which represents one embodiment ofthe ecommerce system of FIG. 3.

FIG. 8 depicts an ecommerce system, which represents one embodiment ofthe ecommerce system of FIG. 3.

FIG. 9 depicts an ecommerce system, which represents one embodiment ofthe ecommerce system of FIG. 3.

FIG. 10 depicts an exemplary computer system.

NOTATION AND NOMENCLATURE

Certain terms are used throughout the following description and claimsto refer to particular system components. As one skilled in the art willappreciate, companies may refer to a component by different names. Thisdocument does not intend to distinguish between components that differin name but not function. In the following discussion and in the claims,the terms “including” and “comprising” are used in an open-endedfashion, and thus should be interpreted to mean “including, but notlimited to . . . .” Also, the term “couple” or “couples” is intended tomean either an indirect or direct electrical connection. Thus, if afirst device couples to a second device, that connection may be througha direct electrical connection, or through an indirect electricalconnection via other devices and connections.

DETAILED DESCRIPTION

The following discussion is directed to various embodiments of theinvention. Although one or more of these embodiments may be preferred,the embodiments disclosed should not be interpreted, or otherwise used,as limiting the scope of the disclosure, including the claims. Inaddition, one skilled in the art will understand that the followingdescription has broad application, and the discussion of any embodimentis meant only to be exemplary of that embodiment, and not intended tointimate that the scope of the disclosure, including the claims, islimited to that embodiment.

In at least one embodiment of an ecommerce system, payment data isdivided into proper subsets and distributed among multiple dataprocessing systems, and each of the data processing systems stores lessthan all of the subsets of the payment data after the subsets of paymentdata are distributed and until at least sending the payment data to apayment authorization system for processing. In at least one embodiment,distributing proper subsets of the payment data among multiple dataprocessing systems enhances security of the payment data by limiting anamount of time and the locations in which a complete set of payment datais persisted.

Furthermore, in at least one embodiment, dividing the payment data intoproper subsets and distributing the subsets among multiple dataprocessing systems facilitates a number of ecommerce systemconfigurations that can, in at least one embodiment, not only enhancepayment data security, but can also allow merchants to accept electronicpayment without the merchant server system coming within the scope ofinformation security standards such as the payment card industry datasecurity standard (PCI DSS). If a data processing system does not fallwithin the scope of the information security standard, the dataprocessing system does not need to incur the expense of complying withthe standard.

As shown in FIG. 2, ecommerce system 200 includes a client computersystem 202 that engages in an ecommerce transaction with a merchant dataprocessing system 204 via the network 206. In at least one embodiment,the ecommerce system 200 divides payment data into proper payment datasubsets to, for example, enhance security and minimize the number ofdata processing systems that fall within the scope of PCI DSSrequirements. Additionally, the ecommerce system 200 can be configuredin any of a number of ways to divide and combine the payment data.

The network 206 can be any type of network, such as the Internet. In atleast one embodiment, the client computer system 202 is a computersystem that includes a web browser software application (not shown) suchas the web browser application 104 (FIG. 1) to allow a user of theclient computer system 202 to receive and transmit data with a merchantdata processing system via the network 206. The merchant data processingsystem is, in at least one embodiment, one of the data processingsystems 204.0-204.N or can be another data processing system such dataprocessing system 208. The network 206 can be any type of network suchas, for example, the Internet.

The data processing systems 204.0-204.N are each part of a separatenetwork in that, for example, each data processing system 204.0-204.Nhas independent and distinct access requirements. In at least oneembodiment, firewalls 214.0-214.N. Firewalls 214.0-214.N permit or denynetwork transmissions to data processing systems 204.0-204.N based upona set of rules to, for example, protect the data processing systems204.0-204.N from unauthorized access while permitting legitimate data topass. Generally the payment data 203 is encrypted and transmitted via asecure connection, such as via a secure sockets layer. Providing thepayment data 203 can be in response to a request to purchase one or moreproducts and/or services offered by one of the data processing systems204.X or data processing system 208.

The ecommerce system 200 can be configured in any number of ways todivide payment data into proper subsets of data. For example, in atleast one embodiment, the client computer system 202 sends payment data203 through the network 206, and N+1 data processing systems 204.0-204.Neach store respective proper payment data subsets S0-SN of the paymentdata. A “proper subset” is a subset that contains less than all elementsof a set. In mathematical terms, if A is a subset of S and A≠S, then Ais called a proper subset of S. “N” is an integer that is greater thanor equal to 1. (Although four (4) data processing systems 204.X areactually depicted in FIG. 2, the number of data processing systems canrange from 2 to N. “X” represents the ith data processing system, and iis an element of the set {0, . . . , N}). In at least one embodiment,the client computer system 202 divides the payment data 208 into theproper payment data subsets S0-SN, and the payment data 203 representsthe proper payment data subsets S0-SN. In at least one embodiment, thepayment data 203 is a complete set, and one of the data processingsystems 204.X, such as data processing system 204.0, divides theaggregate payment data 203 into the proper payment data subsets S0-SN.Data processing systems 204.0-204.N store the respective proper paymentdata subsets S0-SN in respective memories 212.0-212.N.

The ecommerce system 200 can also be configured in multiple ways tocombine the payment data and obtain a payment authorization response. Inat least one embodiment, to request payment authorization, the dataprocessing system 204.X or 208 functioning as a merchant data processingsystem requests at least one of the other data processing systems204.0-204.N to proceed with payment authorization. In at least oneembodiment, when a single data processing system 204.X receives thepayment authorization request, the data processing system 204.X receivesall of the payment data subsets S0-SN, combines the payment data subsetsS0-SN into a single, complete payment data set, and sends the completepayment data set to the payment authorization system 216 for paymentauthorization processing. In at least one embodiment, paymentauthorization system 216 is identical to payment authorization system116 (FIG. 1). In another embodiment, the data processing system 204.X or208 functioning as a merchant data processing system requests the otherdata processing systems 204.0-204.N to send the payment data subsetsS0-SN to the payment authorization system 216. The payment authorizationsystem 216 then combines the payment data subsets S0-SN into a single,complete payment data set and proceeds with the payment authorizationprocessing.

The payment data 203 can be divided into proper subsets of payment datasubsets S0-SN in any number of ways. For example, the payment data 203includes a set of elements that represent values in a payment formpresented to a user of the client computer system 202. Exemplary paymentdata for a credit card holder (also referred to as a “cardholder”)includes a cardholder name, a cardholder billing address, a credit cardnumber, credit card security code, credit card expiration month, andcredit card expiration year. Other payment data can include a creditcard issue month and a card issue year. Assuming that N equals 1, thepayment data 203 is bifurcated into two proper payment data subsets S0and S1 as depicted in Table 1.

TABLE 1 Payment Data Subset S₀ Payment Data Subset S₁ [Billing Address][Expiration Month] [Cardholder Name] [Expiration Year] [Last 4 digits ofcard number] [All digits in card number except last 4] [Security Code][Issue month] [Issue Year]Brackets “[ . . . ]” are used in Table 1 to indicate that the bracketeditem is a value. Note also that the elements themselves can besubdivided. For example, the credit card number is an element and issubdivided into the last 4 digits in the proper payment data subset S₀and the remaining digits in the proper payment data subset S₁.

The payment data subsets S₀-S_(N) are proper data subsets since neitherof the payment data subsets S₀-S_(N) contain all of the payment data203. Additionally, the payment data subsets S₀-S_(N) can be disjoint ornon-disjoint. Regarding the division of data and subdivision ofelements, in mathematical terms, Payment Data={E₀, E₁, . . . ,E_(M)}={S₀, S₁, . . . , S_(N)}, and E_(i)={e₀, e₁, . . . , e_(T)}, S_(y)is selected from the set E_(i) for all i and T. E_(i) is an elementrepresenting an i^(th) element of the payment data. e_(x) is the x^(th)sub-element of an element E_(i). S_(y) is the y^(th) subset of one ormore elements and/or portions of elements of the payment data 203.

The PCI DSS applies to a data processing system when the data processingsystem has access to a complete set of payment data 203. However, sinceless than all of the data processing systems 204.0-204.N have access tothe combined payment data, the number of data processing systems204.0-204.N within the compliance scope of PCI DSS is reduced. In atleast one embodiment, only one data processing system 204.X has accessto the complete set of payment data, only one data processing system204.X maintains PCI DSS compliance. In at least one embodiment, the dataprocessing system 204.X that maintains PCI DSS compliance can respond topayment requests, combine payment data subsets S₀-S_(N), and send thecombined payment data to the payment authorization system 216. In atleast one embodiment, data processing system 204.X momentarily combinesthe payment data subsets S₀-S_(N), thereby minimizing security risksassociated with payment data misappropriation. Thus, the data processingsystem 204.X that maintains PCI DSS compliance can offer PCI DSScompliance as a service to other data processing systems whileminimizing exposure of the payment data to misappropriation.

FIG. 3 depicts an ecommerce system 300, which represents one embodimentof the ecommerce system 200. FIG. 4 depicts a payment data division,aggregation, and payment authorization process 400. In at least oneembodiment, the ecommerce system 300 operates in accordance with thepayment data division, aggregation, and payment authorization process400.

The ecommerce system 300 includes a client computer system 302 thatrepresents one embodiment of the client computer system 202. Theecommerce system 300 also includes N data processing systems DPS₀ _(—)₃-DPS_(N) _(—) ₃, which represent respective embodiments of dataprocessing systems 204.0-204.N. N is an integer greater than or equalto 1. In at least one embodiment, the client computer system 302 anddata processing systems DPS₀ _(—) ₃-DPS_(N) _(—) ₃ are interconnectedvia a network such as the network 206 (FIG. 2). Each of the dataprocessing systems DPS₀ _(—) ₃-DPS_(N) _(—) ₃ includes a firewall(depicted as the outer perimeter) so that each of the data processingsystems DPS₀ _(—) ₃-DPS_(N) _(—) ₃ is a separate system.

Referring to FIGS. 3 and 4, client computer system 302 includes apayment data divider 304 to read payment data and divide payment datainto proper subsets of payment data S₀-S_(N). The particularimplementation of the payment data divider 304 is a matter of designchoice. The payment data divider 304 can be implemented using, forexample, hardware and/or software that can perform hypertext transportprotocol (HTTP) functions. In at least one embodiment, the payment datadivider 304 is implemented as JavaScript, Visual Basic script, and/orFlash. In at least one embodiment, in operation 446, one of the dataprocessing systems, data processing system DPS_(X), provides paymentdata divider 304 to the client computer system 302 for installation inthe client computer system 302. The entity and manner of providing thepayment data divider 304 to the client computer system 302 is a matterof design choice. In at least one embodiment, the data processing systemDPS_(X) is a third party data processing system that facilitatesobtaining payment authorization for a merchant. Operation 446 isdepicted in dotted lines because, in at least one embodiment, thepayment data divider 304 is installed in the client computer system 302as part of the web browser 306 or is included by a manufacturer of theclient computer system 302.

In at least one embodiment, the data processing system DPS_(N) _(—) ₃represents a merchant server system (indicated by the “(MERCHANT)”) thatprovides one or more web pages 303 to the client computer system 302. Inoperation 448, the merchant data processing system DPS_(N) _(—) ₃provides one or more web pages 303 to the client computer system 302. Inoperation 401, the web browser application 306 of the client computersystem 302 renders the web page(s) 303 for display to and review by auser of the client computer system 302. In at least one embodiment, theweb page(s) include data to display products, such as goods or services,offered by the merchant data processing system DPS_(N) _(—) ₃. The userof the client computer system 302 may then decide to enter into acommercial transaction with the merchant for one or more productsoffered in one or more of the web pages 303 and, in operation 403,initiate a checkout process. Operation 403 is depicted using dottedlines because, as subsequently explained in more detail, in someembodiments, the payment data 305 is divided and transmitted inanticipation of a future commercial transaction rather than in responseto a present commercial transaction.

Assuming that the customer and merchant are engaged in a commercialtransaction, the customer continues with the check out process inaccordance with a checkout process established by the merchant dataprocessing system DPS_(X). For example, in at least one embodiment, theuser initiates a ‘buy’ request via the web browser 306, and the webbrowser forwards the ‘buy’ request to the merchant data processingsystem DPS_(X). In operation 405, at least one of the web pages 303includes a payment form, such as a data entry form or shopping cart,which, in operation 405, allows the client computer system 302 to obtainpayment data 305 from the user or from previously stored data for thepurchase of one or more products. In at least one embodiment, inoperation 450, the merchant data processing system DPS_(N) _(—) ₃ alsosends merchant transaction data 301 to associate the merchant with thepayment data 305. The particular content of the merchant transactiondata 301 is a matter of design choice. In at least one embodiment, themerchant transaction data 301 includes a merchant identifier,transaction identifier, and a token to associate the payment data 305with the particular transaction for which the payment data 305 applies.The token allows the client computer system 302 to encrypt the paymentdata 305. In at least one embodiment, the payment data divider 304 hasno ability to store and/or distribute all or part of the payment datasubsets S₀-S_(N) without authorization by the user.

The particular event or events that prompt dividing the payment data 305into the proper subsets of payment data S₀-S_(N) is a matter of designchoice. In at least one embodiment, in operation 403, the clientcomputer system 302 divides the subsets of payment data S₀-S_(N) inanticipation of a future commercial transaction with a merchant serversystem, such as data processing system DPS_(N) _(—) ₃. In at least oneembodiment, in operation 403, the client computer system 302 divides thesubsets of payment data S₀-S_(N) for completion of a financial componentof the present commercial transaction with the data processing systemDPS_(X).

In operation 407, after obtaining the payment data and upon receipt ofan authorization command, such as a ‘buy’ or ‘purchase’ command, thepayment data divider 304 divides the payment data 305 into the N+1payment data subsets S₀-S_(N) prior to distributing the payment datasubsets S₀-S_(N). An embodiment of operation 407 can be implementedusing the following pseudocode:

-   -   read values from the payment form fields, such as credit card        number, expiration month, expiration year, security code,        billing address, cardholder name and issue month and year (if        applicable); and    -   parse the payment form fields and divide the payment data 305        into the payment data subsets S₀-S_(N).

In at least one embodiment, the payment data divider 304 includesparsing and division rules that determine how the payment data 305 willbe allocated to payment data subsets S₀-S_(N). The particular rules area matter of design choice. In at least one embodiment, the payment datadivider 304 specifies how to divide and allocate the payment data 305into the payment data subsets S₀-S_(N). In at least one embodiment, thevalue of N is 1, and the payment data divider 304 bifurcates the paymentdata 305 into two payment data subsets S₀ and S₁ as, for example,presented in Table 1.

After dividing the payment data 305 into the payment data subsetsS₀-S_(N), in operation 407, the payment data divider 304 distributes thepayment data subsets S₀-S_(N) among the data processing systems DPS₀_(—) ₃-DPS_(N) _(—) ₃ in operation 409. In at least one embodiment, eachpayment data subset S₀-S_(N) includes transaction identification data.The transaction identification data associates each of the payment datasubsets S₀-S_(N) with a particular transaction. In at least oneembodiment, the transaction identification data includes data toidentify the particular transaction and an identifier of the merchantfrom which the products are being obtained. When the payment datadivider 304 distributes the payment data subsets S₀-S_(N) “among” thedata processing systems DPS₀ _(—) ₃-DPS_(N) _(—) ₃, each data processingsystems DPS₀ _(—) ₃-DPS_(N) _(—) ₃ receives only part of the paymentdata subsets S₀-S_(N). In at least one embodiment, the payment datadivider 304 utilizes asynchronous JavaScript and XML (AJAX) technologyto distribute the payment data subsets S₀-S_(N) to the data processingsystems DPS₀ _(—) ₃-DPS_(N) _(—) ₃. Additionally, in at least oneembodiment, the payment divider 304 also includes the merchanttransaction data 301, or at least a merchant identifier, as part of eachof the payment data subsets S₀-S_(N).

In operation 454, each of the data processing systems DPS₀ _(—)₃-DPS_(N) _(—) ₃ receives a payment data subset. In at least oneembodiment, data processing system DPS_(X) receives payment data subsetS_(X). In at least one embodiment, to protect the data payment subsetsS₀-S_(N) from fraudulent use, each of data processing systems DPS₀ _(—)₃-DPS_(N) _(—) ₃ encrypts and stores one of the respective payment datasubsets S₀-S_(N) including the merchant transaction data 301 and a useridentifier.

In at least one embodiment, the data processing systems DPS₀ _(—)₃-DPS_(N) _(—) ₃ do not have the ability to return any or all of thepayment data subsets S₀-S_(N) to the client computer system 302. Thus,in at least one embodiment the number of times the payment data subsetsS₀-S_(N) are transmitted is minimized.

In operation 456, at least one, and preferably only one, of the dataprocessing systems DPS₀ _(—) ₃-DPS_(N) _(—) ₃ sends merchant credentialsto the payment authorization system 308 in order to obtain a paymentauthorization response 312. In at least one embodiment, the merchantcredentials include an identifier that identifies the merchant to atleast a payment gateway of the payment authorization system 308. Apayment gateway is typically a system that interacts with a paymentprocessor of a bank used by the merchant. The merchant credentials mayalso include information, such as a password, used to access the paymentauthorization system 308. In at least one embodiment, the paymentauthorization system 308 can be any payment authorization system that,for example, electronically authorizes payment. In at least oneembodiment, the payment authorization system 308 is identical to thepayment authorization system 116 (FIG. 1). A payment authorizationrequest is also sent in operation 458.

Operation 460 aggregates the payment data subsets S₀-S_(N) into anaggregated payment data set 310. The particular system that aggregatesthe payment data subsets S₀-S_(N) into the payment data set 310 is amatter of design choice. In at least one embodiment, one of the dataprocessing systems DPS₀ _(—) ₃-DPS_(N) _(—) ₃ aggregates the paymentdata subsets S₀. In at least one embodiment, the payment authorizationsystem 308 aggregates the payment data subsets S₀-S_(N) into the paymentdata set 310. In at least one embodiment, the system that aggregates thepayment data subsets S₀-S_(N) into the payment data set 310 comes withinthe scope of the PCI DSS. However, in at least one embodiment, the otherdata processing systems that do not have access to the complete paymentdata 310 are not within the scope of the PCI DSS and, thus, do not incurthe costs associated with PCI DSS compliance.

In operation 462, one of the data processing systems DPS₀ _(—) ₃-DPS_(N)_(—) ₃ sends a payment authorization request to the paymentauthorization system 308. The payment authorization request includes thecomplete payment data subsets S₀-S₁, either combined, if aggregated byone of the data processing systems DPS₀ _(—) ₃-DPS_(N) _(—) ₃, orseparate, if aggregated by the payment authorization system 308. In atleast one embodiment, the payment authorization request also includesthe merchant credentials, a transaction amount and currency, and areference identifier for the merchant, if desired. In at least oneembodiment, the payment authorization request is sent using a securetransmission, such as using the HTTPS protocol.

In operation 464, the payment authorization system 308 and at least oneof the data processing systems DPS₀ _(—) ₃-DPS_(N) _(—) ₃ receives thepayment authorization response 312. In at least one embodiment, uponsuccessful authorization, for security if one of the data processingsystems DPS₀ _(—) ₃-DPS_(N) _(—) ₃ has the complete payment data 310,the data processing system DPS₀ _(—) ₃-DPS_(N) _(—) ₃ destroys at leastpart of the payment data 310, such as the payment data subset.1 in Table1.

In operation 466, a request by one of the data processing systems DPS₀_(—) ₃-DPS_(N) _(—) ₃ is made to the payment authorization system 308 tocapture the authorized funds to complete the financial component of thecommercial transaction.

Embodiments of the payment data division, aggregation, and paymentauthorization process 400 can also be implemented by a variety ofecommerce system embodiments. The following description includes severalexemplary ecommerce system embodiments. It will be understood that otherecommerce systems can also implement the payment data division,aggregation, and payment authorization process 400 and variationsthereof.

FIG. 5 depicts ecommerce system 500, which represents one embodiment ofecommerce system 300. The data processing system DPS_(N) _(—) ₅represents a merchant data processing system, and the client computersystem 302 and the merchant data processing system DPS_(N) _(—) ₅conduct a commercial transaction as, for example, described inconjunction with ecommerce system 300. In ecommerce system 500, thepayment divider 304 divides the payment data 305 into the payment datasubsets S₀-S₁, encrypts the payment data subsets S₀-S₁, and distributesthe data payment subsets S₀-S₁ among the data processing systems DPS₀_(—) ₅-DPS_(N) _(—) ₅.

In at least one embodiment, ecommerce system 500 performs operations401-409 and 446-454 as previously described. Data processing system DPS₀_(—) ₅ includes a data aggregator 502 that aggregates all of the paymentdata subsets S₀-S₁. When the merchant data processing system DPS_(N)_(—) ₅ is ready to proceed with payment authorization, merchant dataprocessing system DPS_(N) _(—) ₅ authenticates with data processingsystem DPS₀ _(—) ₅ and sends payment data subset S_(N) includingmerchant transaction data to data processing system DPS₀ _(—) ₅ with arequest to obtain payment authorization from payment authorizationsystem 504 for the transaction identified by the merchant transactiondata. The merchant data processing system DPS_(N) _(—) ₅ also sends arequest to all other data processing system DPS₁ _(—) ₅-DPS_(N−1) _(—) ₅to send payment data subsets S₁-S_(N−1) and merchant transaction data todata processing system DPS₀ _(—) ₅.

Since the data processing systems DPS₁ _(—) ₅-DPS_(N) _(—) ₅ onlyreceive respective proper payment data subsets S₀-S_(N), none of thedata processing systems DPS₁ _(—) ₅-DPS_(N) _(—) ₅ have access to all ofthe payment data 305. Accordingly, in at least one embodiment, dataprocessing systems DPS₁ _(—) ₅-DPS_(N) _(—) ₅ are outside the scope ofPCI DSS, do not need to comply with PCI DSS standards, and, therefore,save costs associated with PCI DSS implementation and compliance.

The data aggregator 502 decrypts and aggregates (i.e. combines) thepayment data subsets S₀-S_(N) into a complete set of payment data. Theparticular aggregation process of data aggregator 502 is a matter ofdesign choice. In at least one embodiment, the data aggregator 502performs a reverse process of payment data divider 304 to reassemble thepayment data subsets into payment data 305. In at least one embodiment,the data aggregator 502 aggregates the payment data into a formatspecified by the payment authorization system 504.

In at least one embodiment, the data processing system DPS₀ _(—) ₅processes the merchant transaction data to determine payment gatewayaccount information for the merchant. The data processing system DPS₀_(—) ₅ then sends the combined payment data, merchant data, and anauthorization request 506 to the payment authorization system 504 inaccordance with the payment gateway account information for themerchant. In at least one embodiment, the merchant data identifies themerchant with a merchant identifier, identifies the transaction with atransaction identifier, and provides merchant account credentials toaccess the payment authorization system 504. In at least one embodiment,the data 506 also includes a token to be used by the paymentauthorization system 504 to decrypt the data 506.

Once the payment authorization system 504 receives the data 506, paymentauthorization system 506 processes the data 506 and generates thepayment authorization response 312 as previously described.

FIG. 6 depicts ecommerce system 600, which represents one embodiment ofecommerce system 500. Ecommerce system 500 bifurcates the payment data305 into proper payment data subsets S₀ and S₁ and distributes thebifurcated payment data subsets to respective data processing systemDPS₀ _(—) ₆ and merchant data processing system DPS₁ _(—) ₆. In at leastone embodiment, the payment data 305 is bifurcated as depicted inTable 1. Ecommerce system 600 functions identically to ecommerce system500 for N=1, except that, in the absence of other data processingsystems, the merchant data processing system DPS₁ does not request anyother data processing systems to send payment data subsets to dataprocessing system DPS₀ _(—) ₆.

FIG. 7 depicts ecommerce system 700, which represents one embodiment ofecommerce system 300. In at least one embodiment, ecommerce system 700performs operations 401-409 and 446-454 of payment data division,aggregation, and payment authorization process 400 as previouslydescribed. After the data processing system DPS₀ _(—) ₇-DPS_(N) _(—) ₇receive respective payment data subsets S₀-S₁, the data processingsystem DPS_(N−7) sends a payment authorization request 702 to thepayment authorization system 704 and sends a request to the dataprocessing systems data processing system DPS₀ _(—) ₇-DPS_(N−1) _(—) ₇directly data processing system DPS₀ _(—) ₇-DPS_(N−1) _(—) ₇ to sendrespective payment data subsets S₀-S_(N−1) to payment authorizationsystem 704. Payment authorization system 704 includes data aggregator706, which combines the payment data subsets S₀-S₁ to complete paymentauthorization. In at least one embodiment, the data aggregator 706combines the payment data subsets S₀-S_(N) as described in conjunctionwith the data aggregator 502. Once the payment authorization system 704aggregates the payment data subsets S₀-S_(N), payment authorizationsystem 704 processes the aggregated data and generates the paymentauthorization response 312 as previously described.

FIG. 8 depicts ecommerce system 800, which represents one embodiment ofecommerce system 300. In at least one embodiment, ecommerce system 800functions identically to ecommerce system 700 except that the dataaggregator 802 is part of a computer system separate from the paymentauthorization system 504. In at least one embodiment, the dataaggregator 802 combines the payment data subsets S₀-S_(N) as describedin conjunction with the data aggregator 502.

FIG. 9 depicts ecommerce system 900, which represents one embodiment ofecommerce system 300. The payment data division, aggregation, andpayment authorization process 400 operations 401-405 and 446-449function as previously described. In ecommerce system 900, the clientcomputer system 902 provides the complete payment data 305 to dataprocessing system DPS₀ _(—) ₉. The data processing system DPS₀ _(—) ₉system includes a data divider 906. Data divider 906 divides the paymentdata 305 into proper payment data subsets S₀-S_(N) as, for example,described with respect to payment data divider 304. Data processingsystem DPS₀ then distributes the proper data subsets S₁-S_(N), alongwith data to identify at least the transaction associated with thepayment data subsets S₁-S_(N), to data processing systems S₁-S_(N).

The payment data 305 can be sent to the payment authorization system 908in any number of ways. For example, in at least one embodiment, dataprocessing system DPS₀ _(—) ₉ recombines the payment data subsets S₀-S₁and sends the complete data set to payment authorization system 908 forprocessing, as described in conjunction with ecommerce system 500. In atleast one embodiment, each of the data processing systems DPS₀ _(—)₉-DPS_(N) _(—) ₉ sends the payment data subsets S₀-S_(N) to either aseparate payment aggregator or to the payment authorization system 908as respectively described in conjunction with ecommerce systems 800 and700. The payment authorization system 908 then generates the paymentauthorization response 312 as previously described.

Thus, in at least one embodiment of an ecommerce system, payment datafrom a client computer system is divided into proper subsets anddistributed among multiple data processing systems, and each of the dataprocessing systems stores less than all of the subsets of the paymentdata after the subsets of payment data are distributed and until atleast sending the payment data to a payment authorization system forprocessing.

The client computer systems and data processing systems described hereincan be completely hardware implemented using, for example, anapplication specific integrated circuit(s) implemented using, forexample, field programmable gate arrays or other logic circuits. Theclient computer system and data processing systems can also beimplemented using a combination of software and hardware. For example,the client computer system and data processing system can also beimplemented as a specifically configured computer system that canperform the processes discussed herein, such as payment data division,aggregation, and payment authorization process 400.

FIG. 10 depicts an exemplary computer system 1000, which can representdata processing systems and the client computer systems describedherein. The processes discussed herein can also be implemented as codestored in a non-transitory, tangible computer programmable medium andexecutable by a general purpose or application specific computingsystem. Examples of a non-transitory, tangible computer programmablemedium include hard-drive memories, solid state memories, such as flashmemories, compact disks, and digital versatile disks.

Referring to computer system 1000, input user device(s) 1010, such as akeyboard and/or mouse, are coupled to a bi-directional system bus 1018.The input user device(s) 1010 are for introducing user input to thecomputer system 1000 and communicating that user input to processor1013. The computer system of FIG. 10 generally also includes a videomemory 1014, main memory 1015 and mass storage 1009, all coupled tobi-directional system bus 1018 along with input user device(s) 1010 andprocessor 1013. The mass storage 1009 may include both fixed andremovable media, such as other available mass storage technology. Bus1018 may contain, for example, 32 or 64 address lines for addressingvideo memory 1014 or main memory 1015. The system bus 1018 alsoincludes, for example, an n-bit data bus for transferring DATA betweenand among the components, such as CPU 1009, main memory 1015, videomemory 1014 and mass storage 1009, where “n” is, for example, 32 or 64.Alternatively, multiplex data/address lines may be used instead ofseparate data and address lines.

I/O device(s) 1019 may provide connections to peripheral devices, suchas a printer, and may also provide a direct connection to a remotecomputer system via a telephone link or to the Internet via an ISP. I/Odevice(s) 1019 may also include a network interface device to provide adirect connection to remote server computer systems via a direct networklink to the Internet via a POP (point of presence). Such connection maybe made using, for example, wireless techniques, including digitalcellular telephone connection, Cellular Digital Packet Data (CDPD)connection, digital satellite data connection or the like. Examples ofI/O devices include modems, sound and video devices, and specializedcommunication devices such as the aforementioned network interface.

Computer programs and data are generally stored as instructions and datain mass storage 1009 until loaded into main memory 1015 for execution.Computer programs may also be in the form of electronic signalsmodulated in accordance with the computer program and data communicationtechnology when transferred via a network. Mass storage 1009 and mainmemory 1015 both are forms of non-transitory storage devices on whichexecutable code can be stored that, when executed by the processor 1013,causes the processor to perform one or more or all of the functionsdescribed herein.

The processor 1013, in one embodiment, is a microprocessor manufacturedby Motorola Inc. of Illinois, Intel Corporation of California, orAdvanced Micro Devices of California. However, any other suitable singleor multiple microprocessors or microcomputers may be utilized. Mainmemory 1015 is comprised of dynamic random access memory (DRAM). Videomemory 1014 is a dual-ported video random access memory. One port of thevideo memory 1014 is coupled to video driver 1016. The video driver 1016is used to drive the display 1017. Video driver 1016 is well known inthe art and may be implemented by any suitable means. This circuitryconverts pixel DATA stored in video memory 1014 to a raster signalsuitable for use by display 1017. Display 1017 is a type of monitorsuitable for displaying graphic images. The computer system 1000described above is for purposes of example only.

The above discussion is meant to be illustrative of the principles andvarious embodiments of the present invention. Numerous variations andmodifications will become apparent to those skilled in the art once theabove disclosure is fully appreciated. It is intended that the followingclaims be interpreted to embrace all such variations and modifications.

What is claimed is:
 1. A method comprising: dividing payment data intomultiple, proper subsets of the payment data; and distributing thesubsets of the payment data and a sender identification data among aplurality of data processing systems wherein each data processing systemreceives less than all of the subsets of the payment data, and whereinat least two of the data processing systems are in separate networks. 2.The method of claim 1 further comprising: receiving a unique paymentdata identification code from one of the data processing systems; anddistributing the unique payment data identification code to the otherdata processing systems to associate each of the respective subsets ofthe payment data with a sender.
 3. The method of claim 1 furthercomprising encrypting the subsets of the payment data prior todistributing the subsets of the payment data.
 4. The method of claim 1,wherein the payment data comprises multiple elements and the methodfurther comprises subdividing the elements into sub-elements.
 5. Themethod of claim 1, wherein the sender identification data comprises anaccess token.
 6. The method of claim 1, wherein the payment datacomprises multiple payment data elements including at least two of acredit card number, a cardholder name, a cardholder billing address, acard security code, card issue month, card issue year, card expirationmonth, and card expiration year, and wherein dividing payment data intomultiple, proper subsets of the payment data comprises generating atleast a first subset of the payment data with at least one payment dataelement and a second subset of the payment data with at least onedifferent payment data element.
 7. The method of claim 1 furthercomprising aggregating the subsets of the payment data.
 8. The method ofclaim 7 further comprising transmitting a request for paymentauthorization for a commercial transaction, wherein the requestcomprises the payment data, a merchant credential, and a transactionamount.
 9. The method of claim 1 further comprising: receiving a propersubset of the payment data; generating a transaction identification codeto associate the proper subset of payment data with the sender; andsending the transaction identification code to a client system toidentify one or more other subsets of the payment data with the sender.10. A non-transitory, computer-readable storage device containingsoftware that, when executed by a processor, causes the processor to:divide payment data into multiple, proper subsets of the payment data;and distribute the subsets of the payment data and sender identificationdata among a plurality of data processing systems so that each dataprocessing system receives less than all of the subsets of the paymentdata, and at least two of the data processing systems are in separatenetworks.
 11. The computer-readable storage device of claim 10, whereinthe software further causes the processor to encrypt the subsets of thepayment data prior to distributing the subsets of the payment data. 12.The computer-readable storage device of claim 10, wherein the paymentdata comprises multiple elements and the software causes the processorto subdivide the elements into sub-elements.
 13. The computer-readablestorage device of claim 10, wherein the sender identification datacomprises an access token.
 14. The computer-readable storage device ofclaim 10, wherein the payment data comprises multiple payment dataelements including at least two of a credit card number, a cardholdername, a cardholder billing address, a card security code, card issuemonth, card issue year, card expiration month, and card expiration year,and wherein the software causes the processor to divide payment datainto multiple, proper subsets of the payment data by generating at leasta first subset of the payment data with at least one payment dataelement and a second subset of the payment data with at least onedifferent payment data element.
 15. The computer-readable storage deviceof claim 10, wherein the software causes the processor to divide thepayment data in response to a receipt of an authorization command tocomplete a sales transaction.
 16. The computer-readable storage deviceof claim 10, wherein each subset of the payment data includes atransaction identifier that associates the subset of the payment datawith a particular sales transaction.
 17. A computer program productcomprising computer executable instructions stored on a non-transitorycomputer readable medium such that when executed by a processor causesthe processor to: divide payment data into multiple, proper subsets ofthe payment data; and distribute the subsets of the payment data andsender identification data among a plurality of data processing systemssuch that each data processing system receives less than all of thesubsets of the payment data, and at least two of the data processingsystems are in separate networks.
 18. The computer program product ofclaim 17, wherein each subset of the payment data is encrypted by theprocessor, wherein the sender identification comprises an access token,and wherein each subset of the payment data includes a transactionidentifier that associates the subset of the payment data with aparticular sales transaction.
 19. The computer program product of claim17, wherein the executed instructions cause the processor to divide thepayment data in response to a receipt of an authorization command tocomplete a sales transaction.
 20. The computer program product of claim17, wherein the payment data comprises multiple payment data elementsincluding at least two of a credit card number, a cardholder name, acardholder billing address, a card security code, card issue month, cardissue year, card expiration month, and card expiration year, wherein thesoftware causes the processor to divide payment data into multiple,proper subsets of the payment data by generating at least a first subsetof the payment data with at least one payment data element and a secondsubset of the payment data with at least one different payment dataelement, and wherein the payment data elements are subdivided intosub-elements.